NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/1926

Internet Message Format | 1996-08-05 | 2.5 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c
Subject: Re: Q: realloc->free?
Date: Wed, 17 Jan 96 18:44:03 GMT
Organization: none
Message-ID: <[e-mail]>
References: <4df2ud$[e-mail]> <4dgic7$[e-mail]> <dan.821890778@handel>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <dan.821890778@handel> [e-mail] "J. Daniel Smith" writes:

>While this is indeed correct, ALWAYS having to write this can make for
>ugly code.

It depends on how you write it. Also malloc/calloc/realloc calls are likely
to make up a very insignificant portion of the source code.

>Let's face it: under normal circumstances, realloc() is not going to
>fail;

Very dangerours assumption which is not bourne out in practice.

>adding code to deal for the extremely rare case can add
>significantly to the complexity of the code.

Adding error checking for heap allocation makes minimal difference to
program complexity. OTOH dealing with rare cases properly makes the task
of debugging much easier.

> And if realloc() does
>fail, there are probably a lot bigger things to worry about than
>leaking memory (like the GUI not being able to create a window to tell
>you something has went wrong).

You can at the very least exit cleanly at the point of failure. If you fail
in allocation you can try to creewate an error window and exit cleanly
if that fails.

>Yes, the above code is more robust than simply
>   a = realloc(a, newsize);
>but this marginal increase in robustness (given the chances of
>realloc() failing in normal operating conditions)

You cannot know what the chances are, especially in a multitasking
system. It is foolish to take any chances when avoiding them is so trivial.

>evaluated against the added complexity of dealing with the failure.
>Yes, the programmer needs to be aware of the fact that realloc() can
>fail, but in some cases ALWAYS checking the return value of realloc()
>just isn't practical given other constraints.

I can't think of any reasonable constraints that would make it impractical.

>C++ is able to deal with this a bit more elgantly via exceptions.

That's fair enough, the point is that in one way or another errors are
dealt with.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------